Parallel Change
課題
consumerに影響のあるインタフェースを変更するには2つの思考モードが必要
変更自体の実装
すべてのconsumer側の更新
複数または外部のクライアントに利用される場合、同時に行うのは難しい
内容
変更をexpand, migrate, contractの3つの異なるフェーズに分けることで、後方互換性のないインターフェイスへの変更を安全な方法で実装するためのパターン
expand
新しいインタフェースを備えるコードの追加
migrate
新しいインタフェースをconsumer側で使うようにする
contract
consumerが移行し終わったら古いコードを削除する
メリット
新バージョンを段階的に試すことができ、リスクを低減できる インタフェースのconsumerがすべて自分のコントロール下にある場合でもステップを分けることでコードベース全体に事故が起こるのを防ぐことができる デメリット
supplierが2つのバージョンをメンテナンスしないといけない contractフェーズを実行しない場合はひどいことになる
インタフェースのusageについてconsumerが混乱する可能性がある
応用例
ほとんどのデータベースリファクタリングはParallel Changeパターンを使う
データベースアクセスするコードが置き換わるまで、旧スキーマと新スキーマの間に移行パターンを設ける 以下はParallel Changeの応用